A one-to-many or many-to-many Internet Protocol (IP) application involves one or multiple sources sending IP messages to multiple receivers. Exemplary applications include the transmission of corporate messages to employees, communication of stock quotes to brokers, video and audio conferencing for remote meetings and telecommuting, and replicating databases and web site information. The IP multicast protocol efficiently supports one-to-many or many-to-many applications by allowing a source to send a single copy of a message to any recipient who explicitly requests to receive the message. IP multicast is more efficient than a point-to-point unicast protocol that requires the source to send an individual copy of a message to each requester thereby limiting the number of receivers by the bandwidth available to the sender. IP multicast is also more efficient than a broadcast protocol that sends one copy of a message to every node on the network even though many of the nodes may not want the message and the broadcast protocol is limited to a single subnet. Furthermore, the IP multicast protocol is applicable not only to wired networks, but also wireless networks. For example, in wireless network, link level multicasting allows several terminals to receive data sent over a single air interface.
IP Multicast is a receiver-based protocol. A receiver subscribes to a multicast session group by sending a join message to the multicast session group. Since the network infrastructure delivers the traffic to each member of the multicast session group, the sender does not need to maintain a list of receivers. The advantage is that only one copy of a multicast message passes over any link in the network. In addition, IP Multicast only creates a copy of the message when the paths diverge at a router. Thus, EP multicast yields many performance improvements and conserves bandwidth throughout the system.
IP multicast is an extension to the standard IP network-level protocol. RFC 1112, titled “Host Extensions for IP Multicasting” and authored by Steve Deering in 1989, describes IP multicasting as “the transmission of an IP datagram to a ‘host group’, a set of zero or more hosts identified by a single IP destination address. IP multicasting delivers a multicast datagram to every member of the destination host group with the same ‘best-efforts’ reliability as regular unicast IP datagrams. The membership of a host group is dynamic; that is, hosts may join and leave groups at any time. There is no restriction on the location or number of members in a host group. A host may be a member of more than one group at a time.” In addition, at the application level, a single group address may have multiple data streams on different port numbers, on different sockets, in one or more applications. Multiple applications may share a ingle group address on a host.
Multicast communications to establish host membership in a multicast group (e.g., a join message) utilize a standard, such as the Internet Group Management Protocol (IGMP), that supports multicast communication at the Open System Interconnection (OSI) data link layer (layer 2). W. Fenner, Internet Group Management Protocol, Version 2, Request for Comments (RFC) 2236, November, 1997, describe IGMP.
In a shared transport media network, encryption takes place at the Open Systems Initiative (OSI) link level (level 2) to prevent an unintended user on the same point-to-multipoint link to get the multicast packets. Alternatively, Internet Protocol security (IPsec) and tunneling can achieve the same result. In addition, in a shared transport network, it is difficult for a provider to determine a total charge to associate with a multicast service between a source and a user because the total charge comprises a content charge and a delivery charge. The source determines the fee associated with the content charge based on the copyright of the content, the volume of data, or a digital right management (DRM) solution. In contrast, the resources consumed during the delivery of the content to a user such as a content provider dictate the delivery charge. In a wireless network, for example, the resources consumed may include wireless radio resources. The content provider is the owner of the multicast data source, however the actual data may be obtained from a third party who owns the copyright to the content.
The content charge and the delivery charge also differ because the content charge accrues against the user and the delivery charge can accrue against either the content provider or the user. If the delivery charge accrues against the content provider for sending the content over a physical network, the accrual of the charge can be on a program basis, a data volume basis, or a time basis. Accrual of the delivery charge against the content provider is suitable for delivering content such as an advertisement because the content delivery benefits the content. The disadvantage, however, is that accrual of the delivery charge against the content provider requires a service agreement between the content provider and the network operator. Thus, when the delivery charge accrues against the content provider, it is not possible to charge for delivery of multicast services originating from any content provider on Internet. If the delivery charge accrues against the user for receiving the content over a physical network, it is difficult to track the volume of data that the user receives. Thus, only two types of charging mechanisms are possible, flat rate charging and program or file based charging. Flat rate charging requires the user to periodically pay a fixed price for using the service. Program or file based charging requires the user to pay a fee for each request to receive a program or file. In response to the payment, the user receives an encryption key that will allow access to the program or file. The program or file can include a software application, audio/video file, or graphic image. The encryption scheme can include link level encryption or IPsec.
Sophisticated and cost-effective charging mechanisms, such as time based charging and data volume based charging, have taken the place of flat rate charging and program or file based charging mechanisms. A charging scheme based on connection time will calculate a fee for a service based on the amount of time that a user connects to the service. For example, if a network operator determines that the rate for using a video service is $5.00 per hour, a user connecting to the video service to view a movie for thirty-minutes accrues a fee of $2.50. A charging scheme based on the volume of data will calculate a fee for a service based on the volume of data that a user receives from the service. For example, if a network operator determines that the rate for using a video service is $0.25 per Megabyte of data received, the fee for a user to use the video service to view a movie consisting of 25 Megabytes is $6.25.
Currently, time based charging and data volume based charging mechanisms are not available for IP multicast deployed in a network with shared transport media Since it is difficult to determine when a user has stopped using a shared transport media service, it is difficult for network to calculate the connection time or data volume received. For example, user may establish a multicast connection through a digital broadcast network, but when the battery in the user's terminal loses a charge, the connection is broken without any indication of disjoining the service. Thus, the charging will continue even though the multicast service is no longer in use. Furthermore, security is a problem because the user has the possibility to disjoin the service, but still receives the data from the shared transport media service. This invention disclosed here is one possible solution to establish a secure billing system for multicast service in a network that is capable for link level multicasting.
Thus, there is a need for a system, method, and computer program product for calculating a cost of receiving multicast data from a multicast session. The system, method, and computer program product will calculate the cost of receiving multicast data based on either the elapsed time that a user connects to a multicast session, or the volume of data received at a destination during the connection period. The system, method, and computer program product disclosed herein establish a secure billing system for multicast services in a network that provides link level multicasting.